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This application claims priority under 35 U.S.C. § 1 19(e) to U.S. 



Application Serial No. 60/155,271 entitled "Method and Apparatus for Determining 
Colimits of Hereditary Diagrams" of Pavlovic et al., filed September 19, 1999, which is 
herein incorporated by reference in its entirety. 



Background of the Invention 

The present invention relates generally to system design and, specifically, to a 
method and system used to refine stratified design specifications, presented as hereditary 
diagrams. 



complex process. While it is possible to design systems fi"om scratch using a minimum 
of design tools, most modem designers use tools to represent and manipulate designs for 
complex systems. 

25 Summary of the Invention 

In the described embodiment of the present invention, a user specifies his design 
using a specification language. Specification software manipulates the specified design 
to yield a more detailed system design. Some of these manipulations involve use of a 
library of specifications. 
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The design of systems, such as computer systems or engineering systems is a 
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Specifications are the primary objects in the described specification language. A 
specification can represent any system or reabn of knowledge such as computer 
programming or circuit design and describes a concept to some degree of detail. To add 
properties and extend definitions, the described specification software allows the user to 
5 create new specifications that import or combine earlier specifications. This process is 
called refinement. Composition and refinement are the basic techniques of appUcation 
development in the described specification software. A user composes simpler 
specifications into more complex ones, and refines more abstract specifications into 
more concrete ones. Refining a specification creates a more specific case of it. 

10 In the described embodiment, specifications can represent an object or concept. 

A complex specification can be presented as a diagram of simpler specifications. A 
software specification is a formal representation of objects or concepts that come about 
in a software development project. In the described embodiment, a complex 
specification can be composed and refined as a diagram of simpler specifications; still 

15 more involved specifications can be composed as diagrams of such diagrams; and so on. 
Large specifications are thus subdivided into diagrams of smaller specifications. The 
process of software design is stratified into such diagrams, diagrams of diagrams and so 
on. This is what is meant by the expression "hereditary diagrams of specification." A 
diagram includes: 

20 •A set of nodes (or vertices) 

• A set of arcs (or edges or arrows), and 

• Two mappings, assigning two nodes to each arc: its source-node and its 
target-node. 

The nodes of a diagram of specifications are formal specifications, capturing the relevant 
25 objects and concepts to be specified, the arcs of a diagram of specifications are the 
"specification morphisms," capturing the relationships between the nodes: how some 
specifications inherit or share the structure specified in others. Diagrams thus provide a 
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graphically based method for software development and refinement, allowing "modular 
decomposition" and reuse of software specifications. 

The described embodiments of the software development tool support: 

• Specification refinement: deriving a more concrete specification fi-om a 
5 more abstract specification by adding more structural detail 

• Code generation: when enough structural detail has been specified to 
determine concrete programming structures suitable to perform the 
required task, code in a suitable language is generated. 

• Colimit determination 

1 0 In general, determination of a colimit is a destructive operation, resulting in the 

loos of information about the involved diagrams. The described embodiments of the 
invention protect and retain the diagrams by folding them into a node. Since the 
described embodiment allow for diagrams of diagrams, this protection can occur in a 
multi-level diagram of diagrams. 

15 Nodes of a diagram show the objects or concepts and arcs between the nodes 

show relationships (morphisms) between the nodes. Diagrams are used primarily to 
create sets of objects and to specify their shared parts, so that the individual parts can be 
combined. Specifications can also be defined to be hereditary diagrams. 

The described specification software allows a user to derive a more concrete 

20 specification fi-om a more abstract specification. In general, the complexity of a 

specification is increased by adding more structural detail. The following techniques are 
preferably used (separately or together) to refine specifications: 

-the import operation, which allows a user to include earlier specifications into a 
later one; 

25 -the translate operation, which allows a user to rename the parts of a 

specification; and 

-the colimit operation, which glues concepts together into a shared imion along 
shared sub-concepts. 
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Use of diagrams (and hereditary diagrams) allows the user to retain information 
about a specification during the design process. The described embodiment of the 
present invention allows a user to define a specification that is a hereditary diagram and 
to perform the colimit operation on the hereditary diagram. 
5 The described embodiments include specification diagrams and compute co- 

limits in this category. Furthermore, the described embodiments iterate this procedure, 
yielding the category of hierarchical diagrams, and computes colimits for these 
hierarchal diagrams. 



Brief Description of the Drawings 
10 Fig. 1 is a block diagram of the overall architecture of an embodiment of the 

present invention. 

Figs. 2(a) and 2(b) are flow charts showing step-wise refinements of a 
specification. 

Figs. 3(a) and 3(b) show a conceptual example of a colimit operation. 
15 Figs. 4(a) and 4(b) show another conceptual example of a colimit operation. 

Fig. 5 shows an example of the colimit operation for a specification. 
Fig. 6 shows an example of the colimit operation for a hereditary diagram. 
Fig. 7 shows another example of the colimit operation for a hereditary diagram. 
Figs. 8(a), 8(b), and 8(c) show an example user interface for the colimit operation 
20 of a hereditary diagram. 

Figs. 9(a)-9(j) show an example of operations initiated by the user to fiirther 
illustrate the colimit operation for a hereditary diagram 

Fig. 10 is a flow chart of a method performed by the exemplary specification 
software to determine a colimit of a hereditary diagram. 
25 Fig. 1 1 is a flow chart showing a first part of the method of Fig. 10 to determine 

a diagram of shape categories. 

Figs. 12(a) and 12(b) provide an example of a hereditary diagram. 
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Fig. 13 provides a more detailed example of the hereditary diagram of Fig. 12. 
Fig. 14 provides an example of a diagram of shape categories for the hereditary 
diagram of Fig. 13. 

Figs. 15(a)-15(d) provide a more detailed example of the diagram of Fig. 14. 
5 Fig. 16 is a flow chart showing additional portions of a first part of the method of 

Fig. 10 to determine a colimit of a diagram of shape categories. 

Fig. 17 provides an example of a colimit of a diagram of shape categories. 
Figs. 18(a)-18(f) provide a more detailed example of the colimit of Fig. 17. 
Fig. 19 is a flow chart showing a second part of the method of Fig. 10 to extend a 
10 diagram in the hereditary diagram in accordance with the colimit of the shape diagram. 
Fig. 20 provides examples of extended diagrams. 

Figs. 21(a)-21(f) provide a more detailed example of an extended diagram. 

Fig. 22 is a flow chart showing a third part of the method of Fig. 10. 

Fig. 23 provides an example of a taking a colimit of extended diagrams. 
15 Figs. 24-26 provide a more detailed example of taking a colimit of extended 

diagrams to yield a colimit of the original hereditary diagram. 

Fig. 27 shows example data structures used in a preferred embodiment. 

Fig. 28 shows example data structures used in a preferred embodiment. 

Fig. 29 is a diagram showing a conceptual view of a set of arcs and a set of 
20 nodes, with a target mapping and a source mapping between them. 



Detailed Descriftion 

General Discussion 

The described embodiment provides a software tool for building, manipulating, 
25 and reusing a collection of related specifications. The tool allows a user to describe 
concepts in a formal language with rules of deduction. It includes a database (library) 
that stores and manipulates collections of concepts, facts, and relationships. The present 
invention can be used to produce more highly refined specifications imtil a concrete 



5 



1 1 128/04483/DOCS/l 092750.1 



level of abstraction is reached. For example, a specification can be refined until it 
reaches the computer source code level. As another example, a specification can be 
refined until it reaches the circuit level. 

Referring now to Fig. 1, there is shown a block diagram of the overall 
5 architecture of an embodiment of the present invention. Fig. 1 includes a data 

processing system 100 including a processor 102 and a memory 104. Memory 104 
includes specification software 110, which implements the refinement methods defined 
herein. Specification software 110 preferably implements a graphical user interface 
(GUI) that allows a user to define specifications and morphisms and that allows a user to 

10 indicate refinements to be performed on the specifications. Specification software 110 
includes or accesses a database 112 that includes definitions of specifications and 
diagrams. The specification being refined is stored in memory 1 14. The refinement 
operations indicated by the user can result in computer code 1 16 if the user chooses to 
perform refinements to the computer code level. 

15 Figs. 2(a) and 2(b) are flow charts showing step-wise refinements of a 

specification during an exemplary design process. In element 202 of Fig. 2(a), the user 
is allowed to define/enter sofl^vare specifications, diagrams, and hereditary diagrams 
(also called a "hierarchical diagram" or a "diagrams of diagrams"). Specifications are 
the primary objects defined by a user. In the described embodiment, specifications can 

20 represent a simple object or concept. A specification can also be a diagram, which is a 
collection of related objects or concepts. As shown in Figure 29, nodes of a diagram 
show the objects or concepts and arcs between the nodes show relationships 
(morphisms) between the nodes. Diagrams are used primarily to create sets of objects 
and to specify their shared parts, so that the individual parts can be combined. 

25 Specifications can also be defined to be hereditary diagrams, where at least one object in 
a node of the diagram is another diagram. 

Specifications can be defined in any appropriate specification language, such as 
the SLANG language defined by the Kestrel Institute of Palo Alto, CA. SLANG is 
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defined in the SLANG Users Manual, available fi-om the Kestrel Institute of Palo Alto, 
CA. The Slang Users Manual is herein incorporated by reference. A specification can 
represent any system or reahn of knowledge such as computer progranuning or circuit 
design and describes a concept to some degree of detail. 
5 In element 204, the user is allowed to start refining his specifications, diagrams, 

and hereditary diagrams. To add properties and extend definitions, the described 
specification software allows the user to create new specifications that import or 
combine earlier specifications. This process is called refinement. Composition and 
refinement are the basic techniques of application in the described specification 

10 software. A user composes simpler specifications into more complex ones, and refines 
more abstract specifications into more concrete ones. Refining a specification creates a 
more specific case of it. 

The described specification software allows a user to derive a more concrete 
specification firom a more abstract specification. In general, the complexity of a 

15 specification is increased by adding more structural detail. The following techniques, 
among others, are preferably used (separately or together) to refine specifications: 

-the import operation, which allows a user to include earlier specifications into a 
later one; 

-the translate operation, which allows a user to rename the parts of a 
20 specification; and 

-the colimit operation, which glues concepts together into a shared union along 
shared sub-concepts. 

Fig. 2(b) is a flow chart of a method for refining a specification. The user 
indicates a refinement operation, which is then performed by specification soflAvare 1 10. 
25 Fig. 2(b) shows three examples of refinement operations. It will be understood that 

other refinements are possible. In element 216, the user indicates that a spec or diagram 
is to be imported. In element 218, the user indicates finding a colimit of a hereditary 
diagram. In element 220, the user indicates a translation of a spec or diagram. 
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In element 206 of Fig. 2(a), the user refines his specification to a level of 
generating computer code. A user may choose not to refine a specification to this level. 
The refinement process can be used for purposes other than generating computer source 
code. For example, the refinement process can be used to help imderstand a 
5 specification. As another example, the refinement process can be used to help verify the 
consistency of a specification. 

The Colimit Operation 

Figs. 3(a) and 3(b) show a conceptual example of a colimit operation. A colimit 
10 is also called "composition" or a "shared union." A "pushout" is a colimit in which a 
colimit is taken of a parent node and its two children nodes. It will be understood that 
the examples of Figs. 3 and 4 are somewhat simplified and are provided to aid in 
understanding of the colimit operation. In Fig. 3, the user has defined a spec "car" 302. 
This specification 302 has been refined by the user as red car 304 and fast car 306. 
15 Thus, the arcs from node 302 to 304 and 302 to 306 are labeled with an "i" (for 
instantiation/import). In Fig. 3(a), the "defining diagram" shows only the 
spec/morphism diagram from which the colimit is formed. Fig. 3(b) shows a "cocone 
diagram," which also shows the colimit and the cocone morphisms (labeled "c"). 

In the described embodiment, the GUI labels arcs as follows, although any 
20 appropriate labeling and morphisms could be used (or none). 

i: instantiation morphism 

d: definitional translation 

t: transitional morphsim 

c: cocone morphism 
25 id: identity morphism 

The defining diagram for a colimit is not limited to a three node diagram. A 
colimit can be taken of any diagram. An example of a different diagram shape is shown 
in Fig. 3(b). In the colimit operation, any type of node related by morphisms in the 
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diagrams are mapped to the same type of node in the colimit. Conversely, any imrelated 
types are mapped to different types in the colimit. The same is true of operations. 

When you compose specifications, types or operations that have the same names 
in different component specifications might be mapped to different result operations. 
5 For example, suppose spec A and spec B are combined to form spec C. Both A and B 
have operations named concat, but the operations do not work the same way, and need to 
be differentiated in spec C. In this case, specification software 1 10 generates 
unambiguous names in the colimit. Similarly, types and operations that have different 
names in the component specifications can be mapped to a single element in the colimit. 
10 For example, the operation concat in spec A and add in spec B might both be mapped to 
a single concatenation operation in the colimit spec C. In this case, the resulting element 
Q preferably has both names. 

f Fig, 5 shows a more realistic example of the colimit operation for a 

specification. In this example, a virtual memory (VM) is a parameter of the operating 

'r'^ 15 system (OS). Suppose we want to formally specify a simple operating system (OS). 

There are large fi-agments of the theory that can be abstracted away. In other words, the 
structure of the system does not depend on a particular virtual memory (VM) 

^3 implementation. Thus, the formal VM requirements can be taken as a parameter of the 

s:3 formal OS specification. Similarly, a particular VM system, VM_0, can be a parametric 

f '1 

}^ 20 in paging policies (PP). Thus, the parameter VM can be instantiated to another 
parametric specification VM_0. 

In this way, a complex system naturally decomposes into simpler components 
that can be refined independently. When all components are implemented, an 
implementation of the whole can be automatically generated: an operating system with 
25 a particular virtual memory management and with a particular paging policy. 

Use of diagrams (specifically, hereditary diagrams) allows the user to retain 
information about a specification during the design process. Taking the colimit of 
simple specifications can destroy the structure of the spec. The described embodiment 
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of the present invention allows a user to define a specification that is a hereditary 
diagram and to perform the colimit operation on the hereditary diagram. This carrying 
information in a diagram brings the colimit operation into lazy mode. Fig. 6 shows an 
example of the colimit operation for a hereditary diagram. Various intermediary choices 
5 can be made by the user as to how to define a diagram. For example, one may wish to 
instantiate the virtual memory parameter VM to VM_0, but to keep the page-in policy 
parameter PP open. The pspec VM_0 can then be protected as a diagram 650. The 
colimit operation can then be applied in the category of diagrams, rather than specs. 
Note that Fig. 6 shows an example of a hereditary diagram in which at least one node is 
10 a diagram. 

The parameter VM to be instantiated for, lifts to a trivial diagram as well as the 
spec OS. The colimit of the resulting diagram yields the spec OS parametric over PP as 
a diagram. 

Fig. 7 shows another example of the colimit operation for a hereditary diagram. 

15 Implementation details of colimits of hereditary diagrams are discussed below in 

connection with Figs. 10-27. Shape changes of even simple diagrams quickly become 
too complex for human beings to solve intuitively. An automated method is needed, 
such as that shown in detail herein. 

Figs. 8(a), 8(b), and 8(c) show an example graphical user interface (GUI) for the 

20 colimit operation of a hereditary diagram. The display of Figs. 8 and 9 preferably are 
generated by specification software 1 10. In Fig. 8(a), the user has defined a hereditary 
diagram. An initial (parent) spec is named Bag-Diagram. Fig. 9(c) shows details of 
Bag-Diagram. (The user may or may not choose to display the detail of the diagram 
Bag-Diagram and may instead display only the name of the diagram as shown in Fig. 

25 8(a)). In this example, the user has refined the parent spec twice, to yield: Bag-as-Seq- 
Dg and Bag-Seq-over-Linear-Order. Figs. 9(d) and 9(e) show details of these diagrams. 
(The user may or may not choose to display the detail of the diagrams and may instead 
display only the names of the diagrams as shown in Fig. 8(a)). 
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In Fig. 8(b), the user has selected the diagram having Bag-Diagram as its parent 
node and has indicated that he wishes to refine the hereditary diagram spec via the 
colimit operation. Although the disclosed interface uses a drop-down menu to allow the 
user to indicate the colimit operation, any appropriate interface can be used. In Fig. 8(c), 
5 the colimit is named Diagram-5. Fig. 9(j) shows details of this diagram. (The user may 
or may not choose to display the detail of the diagram and may instead display only the 
name of the colimit diagram as shown in Fig. 8(c)). 

Figs. 9(a)-9(j) show an example of operations initiated by the user to further 
illustrate the colimit operation for a hereditary diagram. Fig. 9(a) shows an initial 
10 hereditary diagram. Fig. 9(b) shows an example of the result of the colimit operation 
indicated by the user. Fig. 9(c) shows an expansion of the Bag-Diagram requested by 
the user. Fig. 9(d) shows an expansion of the Bag-as-Sequence-Diagram requested by 
the user. Fig. 9(e) shows an expansion of the Bag-Seq-over-Linear-Order-Diagram 
requested by the user. 

15 Figs. 9(f)-9(i) show details of determination of the colimit of the hereditary 

diagram of Fig. 9(a). Fig. 9(f) shows a shape of the shape colimit, which is the shape 
that the colimit will eventually have. Fig. 9(g) shows an extension of the Bag-Diagram 
in accordance with the shape of the colimit. Fig. 9(h) shows an extension of the Bag-as- 
Sequence-Diagram in accordance with the shape of the colimit. Fig. 9(i) shows an 

20 extension of the Bag-Seq-over-Linear-Order-Diagram in accordance with the shape of 
the colimit. Fig. 9(j) shows an expanded version of Diagram-5, which is the colimit of 
the hereditary diagram. Note that the colimit has the shape of the diagram of Fig. 9(f). 

A Preferred Implementation of the Colimit Operation for Hereditary Diagrams 
25 Fig. 10 is a flow chart of a method preferably performed by the specification 

software 1 10 to determine a colimit of a hereditary diagram. In element 1002, the user 
indicates that he wants to take the colimit of a hereditary diagram. An example of a GUI 
to accomplish this indication is shown in Fig. 8(b). When software 1 10 receives such an 
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indication from the user, software 110 preferably performs the remaining elements of 
Fig. 10. In element 1004, software 110 extracts the shapes of the nodes and fimctors of 
the hereditary diagram to yield a diagram of shape categories. Details of this element 
are shown in Fig. 11. Once a diagram of shape categories has been determined, software 
5 110 determines, in element 1004, a colimit of the diagram of shape categories, as 
discussed below in coimection with Fig. 16. 

SoflAvare 1 10 then in element 1006 determines an extension of each diagram in 
the hereditary diagram in accordance with the shape colimit, as is discussed below in 
coimection with Fig. 19. Extending each diagram in the hereditary diagram brings all 

10 diagrams in the hereditary diagram to the same shape, so that it is possible to take the 
pointwise colimit of the extended diagram. Then software 1 10 in element 1008 
determines the colimit of the hereditary diagram using the extended diagrams, as 
discussed below in connection with Fig. 22. Once the colimit is determined, it can be 
stored in memory, saved, or displayed, as the user decides. 

1 5 The following discussion of a preferred software program uses certain abstract 

concepts, which are presented in Table 1, which forms a part of this specification. 
I. Determining a Shape Colimit 

Fig. 1 1 is a flow chart showing a first part of the method of Fig. 10 to determine 
a diagram of shape categories. The elements of Fig. 1 1 are performed for each diagram 

20 in the hereditary diagram. 

First, hereditary diagrams will be discussed. Fig. 12(a) shows a high-level 
example of a hereditary diagram having three nodes dl, d2, d3 (each of which is a 
diagram) and two arcs al and a2 (also called "arrows" or "edges). Each of arcs al and 
a2 represents a shape morphism between a pair of diagrams in the hereditary diagram. 

25 Fig. 12(b) shows a representation of a shape morphism from dl to d2, where F is a shape 
fiinctor and e is a natural transformation from dl to (d2 composed with F). Dl and D2 
are shape categories of respective diagrams dl and d2 and SPEC is the category SPEC. 
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In the described embodiment, the user must specify shape morphisms between 
diagrams when the diagrams are created. Alternative embodiments determine this 
mapping heuristically by, for example, counting the number of arcs in and out of nodes 
or by looking at the type of the nodes. 
5 Fig. 1 3 provides a more detailed example of the hereditary diagram of Fig. 12. 

Here, dl is defined as having three nodes (i, ii, and iii) and two arcs (B and C). Diagram 
62 is defined as having five nodes (0, 1, 2, 3, and 4) and four arcs (a, b, c, and d). 
Diagram d3 is defined as having two nodes (TV and V) and two arcs (A and B) . 

As shown in element 104 of Fig. 10, software 110 determines diagrams of shape 
10 categories. Fig. 14 provides an example of a diagram of shape categories for the 

hereditary diagram of Fig. 13. Diagrams Dl, D2, and D3 represent the respective shapes 
^=3 of dl, d2, and d3. Functions F^ and F„ provide a mapping between the arcs (edges) and 

Cil nodes of each pair of shape diagrams. 

Figs. 15(a)- 15(d) provide a more detailed example of the diagram of Fig. 14. 
15 Mapping Fl between Dl and D2 is shown in Fig. 15(b), Mapping between Dl and D3 
is shown in Fig. 15(c). Source nodes and targets nodes for arcs of the hereditary 
diagram are shown in Fig. 15(d). 

Fig. 16 is a flow chart showing additional portions of a first part of the method of 
Fig. 10 to determine a co limit of a diagram of shape categories. A first element 
20 computes a colimit of the sets of nodes in the hereditary diagram. To do this, the 

soflAvare performs the following: Store in memory a disjoint union of all nodes (ignore 
arcs). Determine the equivalence relations identifying those nodes that are connected by 
some arc of the hereditary diagram. All nodes of the diagrams that fall in the same 
equivalence class are identified as a single node in the colimit. A similar element is 
25 performed to determine the colimit of the arcs. The software then considers the 

relationships between the equivalence classes of arcs and of nodes. For each arc in the 
colimit, the imiversal property (of the sets of arcs) determines a source node and a target 
node in the colimit. 
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Fig. 17 provides an example of a colimit D4 of a diagram of shape categories. As 
can be seen, several of the nodes of the colimit are created by combining nodes in the 
diagrams. Figs. 18(a)- 18(f) provide a more detailed example of the colimit of Fig, 17. 
The combined nodes have been determined to belong to the same equivalence class. For 
5 example, nodes 0 or 4 of diagram D3 do not map to any nodes of Dl or D3. Thus, these 
nodes are not grouped. Arcs b, B, A and arcs c, C, B are grouped, as are nodes 1,3, i, iii, 
IV 2, ii, V. As shovm in Fig. 13, the grouped nodes and arcs belong to the same 
equivalence classes. 

Figs. 18(d)-18(f) show details of the mappings F3, F4, and F5 between the arcs 
10 and nodes or the diagrams in the hereditary diagram and D4. 

n. Extending the Diagrams in Accordance with the Shape Colimit 

In the previous section, we showed how to compute the shape of the 
colimit diagram. In this step we describe the method for computing 
the extension of a diagram along a shape morphism. The following paragraphs provide a 
15 short overview. 

Let m:S -> A be a diagram and let T be the shape of the desired 
diagram, where f:S->T is a shape morphism. The Extension method computes a 
diagram E(m,f):T -> A and a natural transformations eps: m -> f;n, with the imiversal 
property that for any k:T->A and natural transformation alph:m-> f;k, there is a unique 
20 natural transformation sig:n->k such that alph factors through eps: alph = eps;(sig f) 
where is used for vertical composition of natural transformations. 

The method for computing the extension of diagram m along shape 
morphism f, denoted E(m,f), is. 

25 (1) For each node t in T, we form its image imder E(m,f) as follows: 
form the shape f/t whose nodes are 
{<s, i> I i: f(s) -> t is a path in T} 
and whose arcs are 
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{ e I e:s->s' in S and f(e):f(s) -> f(s*) in B and <s,i> and <s',i*> are nodes}. 
E(m,f)(t) is the (spec) colimit of the image of f/t under m. 



(2) for each arc h:y->z in T, E(ni,f)(h) is a unique morphism that 
5 witnesses the universality of the construction of E(m,f)(y). That is, 
h induces a functor from £^y to fiz and thus a diagram morphism dm: 
m(f^y) -> m(£^z). The composition of dm with the cocone morphisms 
from m(f/z) to E(m,f)(z) forms a cocone on m(£^y), so E(m,f)(h) is the 
unique arrow from E(m,f)(y) to E(m,f)(z) that factors the cocone 
10 arrows. 



We have the following property of E: 

Theorem: When T is acyclic, then colimit(m) is isomorphic to 
15 colimit(E(m,f)). 

This theorem asserts that we are neither gaining nor losing 
information in computing the extension of a diagram along a shape 
morphism. We are simply changing its shape. 

20 

The colimit of diagrams enables the automated application of design 
theories to requirement specifications. Knowledge about various kinds 
of software design knowledge (such as algorithm design principles, 
datatype refinements, software architectures, and program optimization 
25 techniques), and other forms of design knowledge, may be represented 
by refinement morphisms from a diagram of the general abstract 
structure A required for applicability of the design knowledge, and an 
abstract specification diagram of a design artifact B. Such a 
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refinement morphism m:A->B is applied to a requirement diagram R by 
first constructing a "classification" morphism c: A->R, and then 
computing the (diagram) colimit R'. The cocone morphism cm:R->R* 
is a refinement of R that embodies the design knowledge in m. 
5 Fig. 19 is a flow chart showing a second part of the method of Fig. 10 to extend 

a diagram in the hereditary diagram in accordance with the colimit of the shape diagram. 
The elements of Fig. 19 are performed for each diagram in the hereditary diagram so that 
each diagram yields an extended diagram. To extend one diagram, the following acts 
are performed. For each node in colimit D4, determine a node in the extended diagram. 
10 Thus, the extended diagram will have the same number of nodes as the shape colimit 
D4. The following are performed for each node n in D4: Find the nodes s in the shape 
a diagram (for example Dl) that have a path i to the node n. This yields a set of pairs of 

m nodes s and paths i: {<s,i> , where I is a path from F(s) to node n in D4). F(s) is the 

node in D4 that corresponds to node(s) in Dl . 
'f'^ 15 For each two pairs in the set (for example, for <Si,i> and <Sj J>, find a path e 

%j between nodes si and sj. Because s^ and Sj have been determined to point to the same 

node, such a path must exist. Once each path e has been found between each pair in the 
set, make a graph of all the <s,i> pairs and take the colimit of the graph. This colimit 
forms one node in the extended diagram. Each arc in the extended diagram is uniquely 
20 defined and determined using the universality of the colimits for the nodes in the 
extended diagram. 

Fig. 20 provides examples of three extended diagrams. The notation, for 
example, LfSdl represents the extension of diagram Dl. 

Figs. 21(a)-21(f) provide a more detailed example of an extended diagram. Fig. 
25 21(a) shows details of Dl and D4 and of the mapping F5, the mapping LfSdl and of the 
mapping between Dl and the extended diagram. The other extended diagrams are 
determined similarly. Fig. 21(b) shows an example of finding the nodes of the extended 
diagram. In Fig. 21(b), the method of Fig. 19 is performed for each node in D4, yielding 
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a colimit that is the extension of the diagram Dl. Fig. 21(c) shows an example of 
deteraiining the arcs of the extension for two of the arcs of D4. In the example, arcs d 
and (CcB) are similar, due to the example chosen. 

Fig. 21(d) shows examples of specs/nodes and arcs that have been predefined by 
5 the user. These specs are used is the mapping between Dl and SPEC in Fig. 21(a). 
Similarly, the arcs are the arcs used in the same mapping. 

Figs. 21(e) and 21(f) are examples of using the specs of Fig. 21(d) to compose 
several specs that will form the nodes of the extended diagram. Note that in Fig. 12(a), 
the nodes and arcs of the extension are defined as mapping LfSdl. Fig. 21(e) 
10 implements the compositions of this mapping. 



15 will be used to determine the colimit of the extended diagrams. 

Figs. 24-26 provide a more detailed example of taking a pointwise colimit of 
extended diagrams to yield a colimit of the original hereditary diagram. 

Fig. 27 shows example data structures used in a preferred embodiment. Fig. 28 
shows a conceptual representation of object-oriented data structures. As can be seen 

20 from the diagram, a hereditary diagram 2802 includes a plurality of objects, at least one 
of which 2804 is itself a diagram 2806. The details of diagram 2806 are not shown for 
the sake of clarity. Of course, diagram 2806 could also be a hereditary diagram. It will 
be imderstood that, although the present implementation uses an object oriented 
programming language, any appropriate implementation method can be used. 

25 From the above description, it will be apparent that the invention disclosed herein 
provides a novel and advantageous system and method of determining colimits of 
hereditary diagrams. 



III. Determining a Pointwise Colimit of the Extended Diagrams 

Fig. 22 is a flow chart showing a beginning of a third part of the method of Fig. 



10. 



Fig. 23 provides an example of the extended diagrams 2300, 2302, 2304, which 
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